In data processing systems, interrupts are used to signal a processor that an interrupt condition exists at a given source. This interrupt source could be, for example, an adapter card on a system bus which requires some type of service. The re,tired service may be to initiate a transfer of data, or to read a status register that has recently changed.
When the processor has been conditioned to accept an interrupt, otherwise known as having the interrupts being enabled, the processor will initiate interrupt processing upon the receipt of an interrupt. This interrupt processing typically involves the processor interrogating the source of the interrupt, performing functions based upon the type of interrupt, and resetting/turning off the interrupt.
At system power-on time, data processing systems typically execute instructions stored in the system's initial-program-load (IPL) read only memory (ROM). This IPL ROM code is relatively primitive in the types of operations that can be performed, and is primarily used to boot-up the system prior to loading and executing the more general purpose operating system software.
Due to the relatively limited intelligence of the IPL ROS code, with the corresponding limited ability to handle the numerous possible combinations of conditions (such as interrupts) that may occur within a system, the bring up of the system at power-on time requires operations to occur in an orderly fashion. To help achieve this objective, many systems are designed such that adapter cards or other sources of interrupts do not generate an interrupt until commanded to do so by the processor. In other words, a routine that is initializing an adapter card may initialize certain registers or internal variables, enable its interrupt processing ability, signal the adapter that is ready to process interrupts, and then wait for the resulting interrupt to be generated by the adapter. These resulting interrupts are thus known as expected interrupts.
During system start-up, before the loaded operating system kernel establishes the system interrupt handlers in RAM, many different type of interrupts may occur. These interrupts can be expected or unexpected/spurious with respect to the interrupt handlers in ROM. A single-thread and non-interrupt driven executing environment of the IPL ROM allows expected interrupts to occur under the control of the IPL ROM code. Most of the time, spurious interrupts are the result of software programming errors.
One attempt to deal with an unused interrupt, which is a particular type of unexpected interrupt, is to treat such unused interrupt as spurious. However, this type of system is lacking in that a valid interrupt may also be spurious in its nature if it is not expected.
There is therefore a need to adequately detect unexpected, spurious interrupts.